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SPG  CBP  f  fc  CAR  DAB 


o 


1st  Annual 
SOS  SE 
Conference 
June  2005 


NDIA 
SE  Conf 
Oct  2005 


March  2005  SSTC 

April  2005 


Stevens  Inst 
SOS  SE 
Workshop  I 
Oct  2005 


Stevens  Inst 
SOS  SE 
Workshop  II 
Jan  2006 


QDR 

2006 


12004 | 

Dor  JCIDS 
5000  3170 


2005 


2006t 


NDIA 

JCIDS/ 

M&S 

Conference 


PA&E 
Costing  SOS 
Study 


AF  Science 
Board  SoS  SE 
Study 


Naval 

Capabilities 

Evolution 

Process 

(NCEP) 
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September  2004  -  MORS  CBP  I 

Systems  Engineering  Implications  of  JCIDs 


CAM/CSE  Activities  and  the  Stacked  V’s 


May  be 

asynchronous 


•  Early  recognition  that 
to  respond  to  CBP  and 
JCIDS,  acquisition 
process  needs  to 
address  the  m 

-  Management  of  the 
collection  of  systems/ 
systems  upgrades 
required  to  address 
user  capabilities 

-Systems  engineer  at 
the  capability  level 

•  Identified  a  set  of  SE 
actions  to  be  addressed 
during  the  transition 
from  JCIDS  to 
acquisition  for  SOS 
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Loomis  et  al.,  MITRE  Corporation 


March  2005  -  SSTC 

DOD  Capability  Based  Approach 
Implications  for  Systems  Engineering* 


•  Further  discussion  of  the 

-Considerations  which  call  for 
an  SE  in  capabilities  definition 
from  the  outset  of  the  CBA 

•  e.g.  need  to  assure  that  new 


-Implications  for  systems 

•  e.g.  optimize  at  capability  vs 
systems  level 

-Organizational/  management 
issues 

•  e.g.  cross  Service  boundaries 
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systems  acquisition  proauce 
systems  which  work  with 
existing  systems  to  meet 
capability  needs 


•  SE  begins  with  JCIDS 

-  FAA,  FNA,  and  FSA  are  the  start  of  SE 

-JCIDS  participation  is  primarily  from  the  uniformed- 
side 

-SE  can  help  in  feasibility  analysis 

•  Capabilities  are  addressed  at  multiple 
levels 

-Initial  Capabilities  Documents  can  be  systems-  or 
SoS-  focused 

-Complex  relationships  among  needs  and  solutions 
(JCDs,  ICDs,  CDDs) 

•  Engineering  and  design  of  increments  of 
capability  need  to  consider  uncertainties 
of  future  needs  in  system  design 

-Calls  for  open,  extensible  systems  approaches  which 
can  support  future,  yet  to  be  defined,  increments 

•  Capabilities  will  be  satisfied  by  a  grouping 
of  legacy,  new  programs,  and  technology 
insertion 

-Solutions  must  be  designed,  developed,  and  tested 
against  capability  areaoenchmarks  (not  optimized  at 
the  system  level) 

•  A  capability  will  cross  Service  boundaries 

-Who  is  the  Capability  sponsor? 

-Who  maintains  prioritization  and  funding? 

-Where  is  Capability-level  SE  performed? 


*  Dahmann/Baldwin,  MITRE  Corporation/ AT&L  Defense  Systems 


October  2005  -  NDIA  SE  Conference 

Systems  Engineering  to  Enable 
Capabilities  Based  Planning* 


Strategy 


Acquisition  Engagement  Across 
Strategy,  JCIDS  and  Acquisition  Processes 

-  Acquisition  ' 


JCIDS  Assessment 


Full  Rate 


i  Decision  ^ 

|L 

System 

Development 

CPD 

Production^  O&S 

l  /\  Analysis  of  /\  Technology 
|  V  Alternatives  V  Development 

H 

Vi — -O 

Incremental 

Development 


OSD/JCS  COCOM 


Planning,  Programming,  Budgeting  and  Execution 


Operational 


Support  Capability 
Based  Assessments 


Define  relationships  with 
related  capabilities, 
architectures  (e.g.,  GIG) 

Identify  alternatives; 


Capability 

Based 

Acquisition 


\  trade  cost,  sched,  perf  \ 

\  Determine  system  \ 

\  performance  parameters 

\  ^ System 

. . . ► 

Systems 
Engineering 
Across  the 
Lifecycle 


and  verification  plans 

Identify  incremental, 
system  specifications 


Component: 


Develop,  test,  and  assess 
increments  of  capability 


C«  T  Basic  Research 
*3<X'  (TRL1-3) 


Applied  Research 
(TRL4-5) 


Advanced  Technology  Development 
(TRL  6-9) 


Extend  to  Enterprise-Wide 
Systems  Engineering  view 

-  Organizational  efforts  that 
focus  on  strategic  objectives 
through 

•  Investment  decisions 

•  Architecture  principles 

•  Standards  and  protocols 

•  Engineering  practices 

-  Measured,  and/or  motivated 
by  a  different  set  of  priorities 

•  Goal-oriented,  organizational 
and  stakeholder  issues 

-  Characterized  by  multiple 
constituents  with  different 
goals  and  priorities 

•  Requires  systems  engineering 
application  to  address  multiple 
systems  and  SoS  constraints 
and  objectives 


*  Baldwin,  AT&L  Defense  Systems 
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June  2005 

1st  Annual  SOS  SE  Conference 


System  of  Systems  Engineering 
Center  of  Excellence 


Sponsored  by  AT&L  DS  Systems  Mission 
Integration  (SMI) 

Brought  together  a  range  of  organizations 
addressing  SOS  from  different  perspectives 

Illustrated  a  strong  interest  in  the  SOS  area 

Demonstrated  the  breadth  of  views  about  the 
salient  aspects  of  SOS  and  different  ways  to 
approach  SOS  theory,  management  and 
technology 


Stevens  Institute  of  Technology 

SOS  SE  Workshops  (Oct  05  and  Jan  06) 

Participants  from  government,  industry,  FFRDCs,  academia 
Focused  on  technical  issues  (not  management) 

Workshop  Accomplishments: 

-  Broad  look  at  impacts  of  complexity  of  systems 

-  Characterized  SE  Process  for  SoS 

-  Addressed  Testing  and  Sustainment  for  SoS 

General  implications  of  SE  at  an  SOS  level: 

-  Traditional  SE  process  is  the  same  for  SoS,  but  the  application  is 
different 

-  Special  case  of  functional  allocation:  Allocate  functionality  to 
systems  which  are  known  to  provide  needed  functionality 

-  Many  unknowns  with  component  systems  (e.g.  Limited  design 
documentation) 

•  Early  emphasis  on  'discovery'  versus  design 

-  Can  you  execute  SOS  in  a  "big  bang"  approach? 

•  Never;  SOS  developments  will  inevitably  be  incremental  improvements 

to  existing  component  systems  7 


AT&L  DAB  Context  Slides 


Example:  CVN-21  Interrelationships 
with  Complementary  Systems* 


EA-18G 
MH-60S 

Combat  Logistics  Force: 
HZTn  AOE-6 
T-AKE 

~n  T-AOE(X) 


AGM-88E 

AIM-9X 

JSOWU 

JASSM 

Fires  /  Fire  Support: 
CEC  |  |  |  | 


Current  schedule  and  performance  support  fielding 

A  t«r\/N91H  t  TVN91  *h  r  r  m'c  tnfhnnlngy  nr  rapah  l  fy 

Arrow  from  CVN-21  denotes  technology  recipients  from  CVN-21 

Performance  issues  with  interface 

OSD  DAES  Rating:  C  S  P  Not  Rated 

□  □ 

*Ref  DAB  review:  Apr  04 

•  Context  slides  showing  system  interdependencies  are 
prepared  for  each  DAB  review 

-To  date  ~25+  context  slides  have  been  developed 

•  Show  programmatic  interdependencies  for 

-Individual  systems 

-Across  the  portfolio  of  Major  Defense  Acqusition  Programs 
(MDAPs) 


Capability  Roadmaps 


Common  Roadmap  Conten 

Chapter  1  -  Introduction 
Chapter  2  -  Policy 

Chapter  3  -  Operational  Concept,  Joint 
Mission  Threads 

Chapter  4  -  Systems  Engineering  and 

Integrated  Architectures 

Chapter  5  -  Program  Evolution 

Chapter  6  -  Key  Initiatives  and  Coalition 
Initiatives 


Based  on  DOD  5000,  there  are  a 
number  of  capability  roadmaps 
underway 

These  roadmaps  each  have 
identified  SE  issues  and  address 
SE  in  different  ways 


Chapter  7  -  Capability  Development  and 
Integration  Management 

Chapter  8  -  Implementation  of  the  DoD 
Net-centric  Data  Strategy 

Chapter  9  -  Net-Centric  Underpinnings  to 
JBMC2 

Chapter  10  -  Experimental 
Technology 

Chapter  11  -  Joint  Test  am 
Chapter  12  -  Summary  am 


2014  2016 


MEMORANDUM  FOR  M:LKk  I  AM  V  (Jt  lilt  ARMY 
SKUETARYOT  IHt  NAVY 
SLC'Rt  I  AMY  or  mu  AIM  FORCE 
CHAIRMAN.  JOINT  C1IIFFS  Of  START 

MflWECT:  InwgriMd  Air  Md  Mtuile  Detente  <IAMI» Capability  Area  Review  (CAR) 
Av«|ut»itiiiii  Declilun  Memorandum  (ADM) 

On  r«bntw  10.  2005. 1  convened  llur  Defama  Aequlaltlnn  ILui.l  (DAB)  fur  an 
1  AMU  CAR.  T1ii>  w«t  I  he  wived  IAMD  CAR.  Our  ibemuinni  inrludrd  the 
MnpuraoM  nl  apaNllty  area  n.\ tdmipi  and  Ihcir  wieih  Htfartmcni’t  declifcat- 

"*‘•■‘•"(1  pnweiuM  Wn  *»,  An . .  tprtifk  linni  nlnled  lu  Uia  IAMI)  mpihility  ana 

and  wtMl  wr  need  to  tui wiplith  m  (I*  owing  inunil* 

We  reviewed  the  IAMD  Rwdmnp,  Venion  I .  Thl»  venrion  huilda  ^ra  the 
ineviuui'y  ^(ciwd  VenlWl  0  by  expanding  Ific  Uxv;  bran  n  system  id  56  opium*. 

tni  hy  Kiyhliyliltnn  impnnuu  . . mg  'truer  IIK  hiding  I  amity  el  hvilcmi  (NR) 

*»Mcm»  engineering,  irtiiny.  and  ml  ready  lapabilliy  Ihv  Joint  Keqwrvmmi 
Overnight  Council  (/ROC)  fan  reviewed  ih»  version  of  the  Rnntaup  and  ihe  Vie* 
Chairmen.  tan I  Chief*  of  Staff  and  I  will  validate  «  and  approve  ii  fur  me  in  maneyiiw 
lire  IAMU  NS. 

I  direct  (fall  another  IAMD  CAR  he  amdiKUd  In  teiund  ipatner  I V  2000.  and  an 
in  progttik  review  he  cimdudcd  in  /um  2005  lo  review  lire actione  rutignad  in  ltu< 

ADM  To  ccemnut  progress  in  development  of  IAMD  ciftihlity,  I  direst  the  following: 


l'rr|ui r  Vmvn  ?  il  the  lAMDKfidmap  by  eewiitrd  igiarwr  |- Y2J 
wiM  further  dev* lop  the  laumrpcroNlily  and  pn'green  tyncl 
•Mussed  in  Venion  I ,  rsamtnr  llnmefand  Air 

Ihc  Ctyuliilily  Hated  Assessment  It  HA  i  Vendor?  2  should  alto  lay  oul  loir.  _ 
reipnnsthllltwi  for  I  oS  level  aunagemetil.  engineering.  and  testing  within  the 
■AMD  eapatilllty  am  ( Anion  Dl  rev  lor,  Detente  Xyiaainn  and  Jotan  Hull  kad) 

I-  tamlac  tAMD  eapahiliry  area  inirrcpcrahUiiy  tad  assess  progress  toward*  (he 
Depariitieni  i  fY200fl  mumper  tUlity  g nalt  io  iiwludr  viiiciia  (Ur  mp4iur1n|| 
»*"¥"•*  and  rorefillmee  w.U.  Nel  Heady  Key  ftrlurmaocc  Parameter  (Aetion: 
Aiuetam  Scvrnary  ..1  Ilrf......  Net  weeks  and  InlurtfiMliin  intrprntiixi  (Nil)  and 

/cam  Sufl'J-61 


In  IAMD  Roadmap  in  particular, 
DAB  direction  focuses  on  roles  and 
responsibility  for  capability  level 
management,  SE  and  test 


"Version  2  should  also  lay  out 
roles  and  responsibilities  for 
FOF-level  management, 
engineering,  and  testing  within 
the  IAMD  capability  area" 
March  2005,  IAMD  CAR  ADM 


Single  Integrated  Air  Picture 


Today’s  warfighting  problems 


System  D 


Everyone  has  a  “picture”  ... 
and  they’re  all  different 


Tailored  system  engineering  process 


•  Achieving  a  common  air  picture 
across  multiple  platforms  and 
sensors  is  a  DOD  objective 

•  The  Joint  SIAP  SE  Office 
(JSSEO)  has  been  addressing 
the  SE  issues  of  this  cross 
systems  capability  need 

•  JSSEO  experience  exemplifies 
the  management  and  technical 
issues  of  SE  of  a  cross  cutting 
enabling  capability  which 

-  Requires  cooperation  and  active 
engineering  participation 

-  From  systems  owned  and 
funded  by  all  the  Services 

-  Which  play  a  critical  role  in 
Service  as  well  as  the  Joint 
environment 
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Joint  Integrated  Air  and  Missile  Defense 
JIAMD  Summit  FOS/SOS  FACT 


Examined  FOS/SOS  issues  in 
integrated  air  and  missile  defense 
mission,  with  a  particular  look  at  the 
Missile  Defense  Agency  joint 
management  and  execution  model  for 
the  Ballistic  Missile  Defense  System 


•  In  2004,  MDA  was  given  control 
over  requirements,  resources  and 
acquisition  of  capabilities  needed 
for  the  BMDS 

-  Created  a  SE  organization  and 
process 

•  Despite  the  freedom  from 
organizational  issues,,  many  of 
the  considerations  raised  in  the 
SOS  SE  discussions  are  faced  in 
the  MDA  case 

-  Systems  which  are  components 
in  BMDS  continue  to  have 
independent  uses  with  needs  and 
development  and  testing 
scheduled 

-  Issues  of  CM  and  sustainment 
apply  here  as  well 

-  Complexity  of  the  components 

mean  that  there  is  continued 
'discovery'  wrt  interactions 
among  systems  when  placed  in 
larger  context  1 1 


SE  Forum 

Naval  Capabilities  Evolution  Process* 


SE  IPT  Capability  Evolution  Planning  Activities 


Draft  guidance  for  SOS  SE  for 
Navy  SOS  (i.e.  Mission 
Capability  Packages  (MCPs)) 

-  Presented  to  SE  Forum 
Recommends  a  process  to 

-  Delineate  requirements  for  at 
capability  level 

-  Decompose  these  into  needed 
functionalities  and  performance 
characteristics 

-  Identify  and  assess  current 
capabilities  to  meet  the 
functionality  needs  of  higher 
level  capability 

Based  on  some  initial  use  cases 


•  Now  out  for  comment 


*  RDA  CHENG,  May  2005 
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Canada's  MOD  Experience 
Capability  Engineering 


Capability 

Gap 


Concurrency  and 
mutual  influences 


Canadian  Department  of  National 
Defence  is  moving  towards  a  'capability 
based  approach' 

-  Began  8  years  ago 

-  Response  to  a  lack  of 

•  Linkage  between  leadership  strategy  and 
acquisition  programs 

•  Coherence  across  acquisition  programs 

-  Still  working  toward  integrated  process 

One  focus  of  their  efforts  is  Capability 
Engineering  (CE) 

-  Application  of  SE  processes  to 
capabilities  [discussed  at  MORS  CBPII] 

Concepts  have  been  developed  and 
initial  applications  are  underway 

Provides  an  opportunity  for 
collaboration  for  US  SE  work  to  addr§§s 


SE  Forum 

Air  Force  Science  Advisory  Board  on  SOS 

SE* 


$o$E  Process 


*  SAB-TR-05-04,  July  2005 


•  Presented  to  SE  Forum 

•  Emphasized  a  strong  role  for 
experimentation  in 
understanding  requirements 
and  defining  development 
approaches 

•  Driven  by  the 

-  New  capability  is  composed 
of  numerous  extant  systems 

-Understanding  opportunities 
for  combined  effects 
requires  discovery 

•  Opportunity  to  understand 

-  Implications  of  using 
multiple  systems  in  new 
ways  (second  order  effects) 

-  Users  to  assess  how  much  is 

enough  14 


Decision  Support  Center 
JDSETES* 


UNCLASSIFIED 

Joint  Capabilities  Acquisition  Gap  (U) 

JDSETES  Study 


MILDEPs  (Title  10) 


Who  does  the 
Systems  Engineering 
of  Joint  Capabilities? 


Programs 


Joint  Capability  A 


Joint  Capability  B 


Programs 


Joint  Capability  C 


Programs 


Marine  Corp 


Who  does  the  cross- 
program,  cross¬ 
component  trades? 


Programs 


JFCOM  /  COCOMS  Title  50) 


Acquisition  Space 
Army  - 


Joint  Warfighting  Space 


Jointness  Needs  To  Be  Designed-In,  Not  Just  Tested-Out 


) 


8  4/6/2006  JDSETES  Final  Briefing  V13.ppt 


UNCLASSIFIED 


Study  sponsored  by 
AT&L  and  Nil 

Calls  for  emphasis 
on  SE  for  SOS 

Necessary 
perquisite  for 
environments  to 
support  SOS  SE 
and  test 
environments 


*  Joint  Distributed  Systems  Engineering  and  Test  Environment  Strategy, 
Study  Draft  Final  Report,  April  2005 


Balancing  Federation  Development  and  rC3 
Individual  Simulation  Development  — . 


Users 


Systems  Engineering 


Requirements 

Definition 

Design 

Development 

nteg  ration 

Use 

Requirements 

Definition 

Design 

Development 

Integration 

Use 

1 

I 

Requirements 

Definition 

Development 

Integration 

Testing 

Use 

Requirements 

Definition 

Development 

Integration 

Testing 

Use 

Models 


Federation  Systems  Engineering 
requires  the  coordination  of  SE 
processes  across  all  aspects  of 
the  SE  process 


MITRE 


S  A 

Define 

Federation 

Objectives 

© 

S  \ 

Perform 

Conceptual 

Analysis 

- > 

Design 

Federation 

r  a 

Develop 

Federation 

Plan. 
Integrate, 
j-  T 

/  > 
Execute 

Federation 

and 

f 

Analyze 
Data  and 
Evaluate 

© 

V _  _ > 

© 

V _  v 

® 

v. - , - > 

Outputs 

© 

V _ „ _ J 

u 

J!t- 


J  ! 


+-  I 


Correcfve  Adorn Rear  dive  Development 

Figure  1 — Federation  development  and  execution  process  (FEDEP),  top-level  view 


1516.3  IEEE  Recommended  Practice  for  High  Level  Architecture 
(HLA)  Federation  Development  and  Execution  Process  (FEDEP) 


Experience  with 
M&S SOS 

•  For  years  the  M&S 
community  has  been 
engineering  federations  (or 
systems)  of  simulations  to 
address  evolving,  complex 
M&S  needs  (e.g.  DIS,  HLA, 
TENA) 

•  Federation  development  and 
execution  process  (FEDEP) 
provides  an  experience  base 
for  operational  systems 

•  IEEE  standards  for  this 
process  (IEEE  1516) 
provides  insights  into  what  is 
different  about  SE  needs  for 
composing  SOS  (M&S 
federations)  vice  developing 
new  systems  (simulations) 
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MITRE  Enterprise  Systems  Engineering  Model* 


•  Based  on  experience  with  increasing  complex,  interdependent 
systems 

•  Addresses  increases  in  external  influences  which  constitute  the 
environment  in  which  SE  is  conducted...  and  affect  the  way  SE  is 
conducted 


Scales 


Enterprise 

Systems  Engineering 


Capabilitie' 


I  I 


Groupings 


Enterprise 

Sub-enterprise 


Patterns 


Q 


Constraints 


System  of  Systems 
Engineering 


Tens  of  SRjT 

System  of  Systems 
(Mission  Strings)  -QOI1- 


Functioualitv 


I  I 


Constraints 


System 

Engineering 


Hundreds 
of  Independent 
Systems 


Figure  3.  Systems  Engineering  Scales 


.  2006  INCOSE 


Business 

Processes 


Enterprise  Management 

Vision 

Goals 

Conflict  Mgt 
Roles  &  Resp 

___  Reg  Dev  S  Mgt 

ese  Risk  Mgt 

Strategic  Technical  Plan  config  Mgt 

Enterprise  Architecture  project  pil>g 

Cap  Planning  Analysis  qa 

Technology  Planning  System  Safety 

ILS 

l  Restructure 
The 
Enterprise 


Process 
Improvement 
(CMMI) 


A 


Diagnostic®^ 

^Analysis  &  Assessment^^Jmeg  rated  Test 

En 

erprise  Assessment 

Figure  5.  The  MITRE  ESE  Model 


Traditional 

Systems 

Engineering 

Process 

Areas 


Areas  of  General  Agreement  on  SOS  SE 

Capabilities  which  go  beyond  an  individual  system  need 
benefits/discipline  of  SE 

Lack  of  a  capability  level  management  has  inhibited 
progress  toward  capability  areas  SE 

SE  top  level  activities  apply  to  SE  for  capabilities 

-  Albeit  with  different  constraints  or  emphasis 

Major  SE  issues  surround 

-  Lack  of  definition  of  capability  level  requirements,  needs  or 
objectives 

-  Competing  demands  on  systems  and  management  of  multiple 
versions  (CM,  scheduling) 

•  Own  requirements 

•  Requirements  of  SOS 

•  Requirements  of  other  SOS's 

-  Synchronizing  development,  integration  and  test 

-  Testing,  given  complexity  and  scope 

Multiple  ownership  and  control  of  systems  is  source  of 
management  issues  and  has  implications  for  SE  process  i8 


Open  Issues 


•  Approach  to  capability  specification  and  design 

-  Extend  standard  SE  process  and  do  full  design  for  SOS  and  then 
assess  ways  to  adapt  existing  capabilities  to  meet  new  needs 
(Navy  NCEP) 

-  Conduct  design  only  to  first  level,  integrate  current  systems, 
evaluate  base  level  of  capability,  and  improve  in  areas  as 
needed  (Navy  NIFCA,  M&S  Federation) 

-  Begin  with  experimentation  as  basis  for  design  (AFSAB) 

•  Balance  between  'top  down  design  and  engineering'  and 
'bottom  up  consensus  based  collaborative  approach' 

•  Role  of  'architecture' 

-  Starting  point  (IT  view) 

-  Product  of  SE  process  (SE  view) 


Limited  experience  in  DOD  to  help  address  these  issues 
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QDR  Implementation 


Capability  Portfolio  Management 
Options 


Status  Quo 

Alternative  Solutions 

Common  Framework 

(Federated  Ownership) 

Joint  Management 
Mechanism 

(Decentralized  Execution) 

_  Joint 
Execution 
Mechanism 

Example 

Most  Defense 
Activities 
(JCIDS  uses 
Capabilities) 

^Mobility  Capability  Study 
^Global  Basing 
^DAB  Capability  Area 

Reviews  (not  same  as  JCAs) 

'CJoint  National  Training 
^Nuclear  Portfolio  ? 
v'BRAC 

^MDA 

^British  Model 

Roles  & 

Authorities 

Changes 

None 

None 

Moves  Money  control 

Massive 

Restructuring 

Outcome 

Aligns  the 
“Likes” 

Provides  a  Common  Decision 
Framework  for  Enterprise 

Level  Decisions 

Reorganizes  Resource 
Allocation  at  the 

Joint/Enterprise  Level 

Can  clearly  link 
strategy, 
requirements, 
funding,  acquisition 
and  outcomes 

Scope  of 
Change 

Limited  and 
Marginal 

Can  be  significant,  but  takes  a 
lot  of  effort  to  execute  a 
decision 

Depends,  Can  be  significant, 
establishes  enterprise  level 
accountability,  less  effort  to 
execute 

Can  be  done,  butt 
certainly  difficult 

Comments 

Focused  on 
Programs, 
“bottoms  up” 
Dominated  by 
Suppliers 

Common  Facts  &  Thinking 
about  Portfolios, 

Ties  Funding  Allocation  to 
Portfolios,  creates 
transparency,  top  down, 
horizontally  integrates 

Organizes 
management  and 
execution  around 
Portfolios  under  one 
accountable  entity 

•  QDR  focused  on 
need  for  joint 
capabilities 

•  Addresses 
selected  priority 
areas 

•  Examines 
different  'models' 
for  managing 
joint  portfolios 

•  Joint  portfolio 
management  and 
execution 
requires 
coordinated 
development  of 
interoperable 
systems 

SE  Implications 


Way  Ahead 


•  Continue  investigation  and  coordination  of 
numerous  SoS  SE  experiences 

•  Support  ongoing  capability  areas  and  portfolios 

-  Define  needs  of  QDR  portfolios 

•  Leverage  OSD  SE  Forum 

-  Linkage  to  broader  SE  community 

-  Basis  for  SE  guidance  and  policy  updates 

-  Develop  SoS  SE  Guide 

•  Capture  knowledge  gained  from  experiences 

•  Augment  existing  policy  and  processes 
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Way  Forward:  SOS  SE  Guidebook 

Goal:  Develop  DoD  SE  guidebook  for  SoS 

Tasks: 

•  Classify  types  and  approaches  of  SoS  (Enterprise  Systems,  Adaptive 
Systems,  C2  Systems,  ISR  Systems,  etc.) 

•  Conduct  survey  of  best  commercial  and  DoD  SoS  SE  practices 

•  Review  and  leverage  existing  policies,  procedures  and  approaches. 
Example:  Navy  capability  engineering  process 

•  Review  results  of  SE  assessments 

•  Develop  list  of  key  planning  enablers  for  successful  SoS  SE 

•  Organize  process  in  logical  progression  steps 

•  Define  boundaries,  if  any,  and  relationship  to  program  management 

•  Develop  DoD  guide 

Deliverables:  Final  SoS  SE  guide  by  end  of  November  06 
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